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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 

Syndicated feeds, using technologies such as Atom and Really Simple Syndication (RSS), are widely used on today's 
Internet for various scheduled pull applications such as podcast. There are a number of non-compatible proprietary 
extensions and a number of different RSS variants that may need to be installed and updated. 

OMA DCD has defined Channel and Content Metadata and related mechanisms for content delivery (including RSS 
and ATOM feeds) using Content Metadata XML extensions independently of any bearers. As a consequence there are 
no specific optimizations for 3 GPP services/bearers. OMA DCD specification allows embedding of OMA DCD XML 
namespace elements into RSS and Atom document (RSS and Atom feed "content packaging formats"). The OMA DCD 
Channel and Content Metadata are intended to offer different content delivery alternatives to receivers. 

The Syndicated Feed Reception (SFR) specification intents to define the optimized reception for any existing 
syndicated feeds using 3 GPP specific bearers. SFR re-uses OMA DCD procedures and metadata for client server 
transactions. 



ETSI 



3GPP TS 26.150 version 10.0.0 Release 10 6 ETSI TS 126 150 VI 0.0.0 (2011-04) 



Scope 



The present document defines a set of media codecs, formats and transport/application protocols to enable syndicated 
feed reception within the 3 GPP system. 

The present document includes information applicable to network operators, service providers and manufacturers. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

- For a specific reference, subsequent revisions do not apply. 

- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 
[2] 3GPP TS 41.001: "GSM Specification set". 

[3] RSS Advisory Board: "Really Simple Syndication 2.0". 

[4] IETF RFC 4287: "The Atom Syndication Format" . 

[5] Open Mobile Alliance:: "OMA Dynamic Content Delivery Vl.O", June 2009. 

[6] 3GPP TS 26.234: "Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols 

and codecs". 

[7] 3GPP TS 26.244: "Transparent end-to-end packet switched streaming service (PSS); 3GPP file 

format (3GP)". 

[8] 3GPP TS 26.346: "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs". 

[9] Open Mobile Alliance: "OMA Push V2.2", June 2009. 

[10] IETF RFC 4281: "The Codecs Parameter for Bucket Media Types", Gellens R., Singer D. and 

Frojdh P., November 2005. 

[II] Open Mobile Alliance: "User Agent Profile Version 2.0", February 2006. 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. 

Syndicated Feed: A document, formatted according to RSS, ATOM, DCD or other syndicated feed formats, which is 
frequently updated with new content updates. 

Syndicated Feed Reader: The client, which receives and processes one or more syndicated feed formats. 
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Syndicated feed URI: A Uniform Resource Identifier, pointing to the document, which is formatted according to RSS, 
ATOM or other syndicated feed formats. 

Syndicated Feed Provider: A content provider, which uses HTTP servers to provide syndicated feeds for download. 

SFR enabled Feed Reader: A feed reader, which is able to use optimized receptions and/or optimized enclosure 
handling as defined in the specification. 

SFR Server: Server, which offers methods for optimized reception of syndicated feeds for SFR enabled Feed Readers. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

GPRS General Packet Radio Service 

IP Internet Protocol 

DCD Dynamic Content Delivery 

MBMS Multimedia Broadcast/Multicast Service 

PSS Packet Switch Streaming 

RSS Really Simple Syndication 

SFR Syndicated Feed Reception 

UE User Equipment 

URI Uniform Resource Identifier 

URL Uniform Resource Locator 

XML extensible Markup Language 



4 System description 

4.1 Functional overview 

The following diagram (see Figure 1) illustrates the overall system for syndicated feed reception (SFR). The system is 
subdivided into an SFR enabled Feed Reader, a SFR server and Syndicated Feed Provider. 

SFR enabled Feed Readers are clients, which provide all the functionality to parse, process and (opt.) present syndicated 
feeds. The SFR enabled Feed Reader can interact with any legacy syndicated feed server (e.g. RSS or Atom) using 
HTTP. Additionally, those clients are also able to optimize the syndicated feed reception and/or optimize the handling 
of enclosures as defined in this specification. SFR enabled Feed Readers may support one or more syndicated feed 
formats such as RSS or Atom. From an implementation/deployment perspective, the SFR enabled Feed Reader can be 
shared by multiple ATOM/RSS -based applications or could be incorporated as a part of such an application. 

SFR enabled Feed Readers, which include "optimized reception" of feed updates and/or enclosures support interactions 
with SFR servers. 

SFR servers offer the SFR enabled Feed Reader with functions to optimize the reception of feed updates, attached 
media and enclosures. SFR servers interact with one or more syndicated feed servers. The interaction protocols and 
procedures of SFR server with Syndicated feed servers are out of scope of this specification. The SFR server is a 
profiled OMA DCD server dedicated to optimize syndicated feed delivery. 

Syndicated feed providers are legacy functions, which use HTTP to offer their syndicated feeds. 
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Figure 1 : Overall SFR System 

The SFR enabled Feed Reader interacts with the SFR server in order to get an optimized reception of syndicated feeds 
using the "Admin" reference point. The SFR server provides the SFR enabled Feed Reader with feed content using 
OMA Push or MBMS download delivery using the "Push" reference point. The "Pull" reference point is used, when the 
SFR enabled Feed Reader pull content from the SFR server. The "Admin", "Push" and "Pull" reference points are 
realized using a subset of the OMA DCD-3, DCD-2 and DCD-1 reference points [5]. 

The "Admin" transactions between SFR enabled Feed Reader and SFR server re-use a subset of the OMA DCD-3 
transactions. The "Push" procedures between SFR server and SFR enabled Feed Reader re-use the OMA DCD-2 
transactions (see section 5.6) and extend them to cover MBMS delivery via direct binding. The "Pull" Interface to the 
SFR Server corresponds to "DCD-1 ". The "Pull" procedures between SFR server and SFR enabled Feed Reader re-use a 
subset of OMA DCD-1 transactions (See section 5.6). The SFR enabled Feed Reader implements a profile of the DCD 
client and supports some of the DCD Enabled Client Application (DECA) functionalities. 

The "Poll" interface to the syndicated feed provider (dashed line) corresponds to the stateless pull of legacy syndicated 
feed readers using HTTP. The "Poll" interface is not in scope of this specification. 

The profiling of DCD [5] is defined in section 5.7. 



4.2 Operations overview 



Syndicated Feed Reader, which want to use "optimized reception" as defined in this specification must first activate and 
register with the SFR server to establish a session and then initiate the optimized reception of desired Syndicated Feeds 
(i.e. also called channels). 

The SFR server provides the SFR enabled Feed Reader with a session-id as value of the Session-ID field in the 
activation response message that corresponds toa successful activation. This session-id is used during all later 
transactions. One or more syndicated feed reception channels may be added to or removed from the session at any point 
in time. 

The SFR enabled Feed Reader use the Syndicated Feed URI (content address) of the syndicated feed to initiate the 
optimized reception. The SFR Server shall use the content address of the syndicated feed as value for the Channel-ID 
field. The Channel-ID value is used to identify specific syndicated feeds during later transactions. The Channel-ID 
value is present at any syndicated feed related transaction. 

The session is persistent, even if the UE is switched-off . However, all or some channels can be suspended. The UE may 
suspend some or all syndicated feeds when roaming in foreign networks by sending a channel suspend request to the 
SFR server. The SFR enabled Feed Reader may also indicate as part of the channel subscription procedure that while 
roaming, content delivery shall automatically be suspended. In that case and upon detection that the UE is roaming, the 
SFR server shall suspend the delivery. 

Each transaction on the "Admin", "Push" and "Pull" reference point is uniquely identified by a transaction-identifier, 
which is provided with the value of the Message-ID field. The value of the Message-ID field is composed of a unique 
transaction-id identifier followed by two numeric characters for message index within the transaction. The transaction 
identifier is the same for all related messages of a transaction within a session. 
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The SFR enabled Feed Reader can find e.g. the response to a certain request message based on the transaction- 
identifier. All messages belonging to the same transaction shall use the same transaction identifier value in the 
Message-ID field. 

Example of message-id: 

Transaction id= 01178AC32 

Message id = 01178AC3200 for the first message, and message id = 01178AC3201 for the second message. 

5 Protocols and procedures for optimized feed 

reception 

5.1 Introduction 

SFR is a profile of the DCD enabler [5] dedicated to ATOM, RSS content delivery and reception. 



5.2 Syndicated Feed Discovery 



Syndicated feed discovery refers to methods for the UE to obtain a list of available syndicated feeds with the intent to 
activate the reception of one or more syndicated feeds. As part of the optimized delivery of SFR, two methods for 
discovering a feed (internal discovery and external discovery) are specified. 

The UE may discover syndicated feeds either through the SFR enabled Feed Reader, an external UE application (such 
as the browser) or an external device (such as a browser on a PC). Syndicated feeds can also be discovered through an 
external device (such as a PC browser) and the syndicated feed reader in the UE may be notified to initiate the 
reception. This external reception initiation is further defined in section 5.4.3. 

Using an external UE application for syndicated feed discovery is defined in 5.2.1. The syndicated feed URI is given to 
the SFR enabled Feed Reader. 

Using the SFR enabled Feed Reader for syndicated feed discovery is defined in section 5.2.2. The Syndicated Feed 
reader retrieves information about all available feeds from the SFR server. 

5.2.1 Feed Discovery using an external UE application 

The user discovers available syndicated feeds using an external UE application such as a UE browser. The external UE 
application makes the feed URI available to the SFR enabled feed reader. 

The SFR enabled Feed Reader gets the feed URI as input and then needs to determine if it is an SFR optimized feed or 
if it is a regular ATOM/RSS feed. Details for the syndicated feed subscription are defined in section 5.4. 

An example of feed discovery using an external UE application is described in clauses A.l and A.4. 

The feed can be available at a new SFR server with which the SFR enabled Feed Reader is not configured. In such case 
the SFR enabled feed reader needs to activate to the new SFR server in order to receive feeds. This activation process is 
specified in sections 5.3.2.2,5.3.3 and 6.1.1 of [5]. 

5.2.2 Feed Discovery using the SFR enabled Feed Reader 

The SFR enabled Feed Reader includes methods for feed discovery. The SFR enabled Feed Reader is already activated 
and registered to an existing SFR server. The syndicated feed reader receives a list of available syndicated feeds from 
the SFR server. An initial list, the Channel-Guide List, of syndicated feeds is received with the 
ApplicationRegistrationResponse message (see section 5.3). 
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Figure 2: Channel Discovery 

The SFR enabled Feed Reader uses a subset of Channel Discovery methods defined in section 7.1.3.10 of [5]. 
Information Elements (IE) of the ChannelDiscoveryRequest Message: 

• Message-ID: Mandatory in OMA DCD and SFR. 

• Session-ID; Mandatory in OMA DCD and SFR. 

• Channel-Metadata: Mandatory in OMA DCD and SFR. The relevant subset for SFR is defined in section 5.7. 
Information Elements (IE) of the ChannelDiscoverylnfo Message: 

• Session-ID; Mandatory in OMA DCD and SFR. 

• Message-ID: Mandatory in OMA DCD and SFR. 

• Channels-added: Conditional in OMA DCD and SFR. 

• Channels-removed: Conditional in OMA DCD and SFR. 

• Channels-updated: Conditional in OMA DCD and SFR. 

An example of feed discovery using the SFR enabled Feed Reader is described in Annex A.2. 

5.3 Activation for Syndicated Feed Reception 

5.3.1 Introduction 

Reception activation procedures of OMA DCD [5] are re-used to activate optimized reception of syndicated feeds. 

5.3.2 Activation triggered by the client 



5.3.2.1 



Activation to a default SFR server. 



The SFR enabled Feed Reader is configured to a default SFR server. See section 5.1 of [5] and perform the activation to 
that SFR server. Details of the activation parameters are described in section 5.3.2.3 



5.3.2.2 



Discovery of a new SFR server via URI scheme 



The SFR enabled Feed Reader shall be able to identify whether this feed is an SFR feed or a legacy ATOM/RSS feed. 
The syndicated feed URI follows a predefined URI scheme in order to identify the SFR server and provide relevant 
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connection parameters associated with the SFR server. If such a feed URI is identified the SFR enabled Feed Reader 
uses the SFR parameters contained in the URI scheme to send an activation request to the SFR server. 

Example of flow: 



Browser 



SFR enabled 
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Web 
Server 



Feed 
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1 ) Feed Discovery 



HTTP GET Web-Page URI 



Retrieve parameters from the URI 
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-\ /-T 

New Content ^^^ ^^"^ | 



Figure 3: Discovery of a new SFR server via URI sclieme 

In order for SFR enabled Feed Reader to connect to a new SFR server the following parameters shall be included in the 
URI (based on DCD-3 connection profile see Section 8.1.2 of [5]): 

• SFR server address: address (URL) of the SFR server with which the SFR enabled Feed Reader should 
activate. 

• Proxy: address (IP address or hostname) of the proxy that should be used for communications with SFR server. 
This parameter may be omitted if no proxy is required to connect to the SFR server. 

• Data connection details: Additional bearer-network- specific connection details e.g. APN, data connection 
username/password, etc. This parameter may be omitted if no additional data connection details are required to 
connect to the SFR server. 

Example of SFR URI: 

<http://www.SFR.org/abcTopNews ? server-address=' 10.24. 122.26:8080' > 

Upon reception of these parameters, the SFR enabled Feed Reader shall send an activation request message as specified 
in section 7.1.3.1 of [5] to the server address retrieved as part of the URI parameters. Once the SFR enabled Feed 
Reader activation is complete, an SFR enabled Feed Reader sends registration and channel subscription request(s), as 
specified in [5]. 

The SFR enabled Feed Reader may combine all 3 requests into a single request using multipart HTTP requests. With 
this approach the assumption is that authentication (basic, digest, or TLS) associated with activation request is sufficient 
to facilitate registration and subscription combined into the single transaction with activation. In other words, as 
registration and subscription requests are bundled with authenticated activation request there's no need to send session 
ID with these requests. 

Details of the activation process are described in 5.3.2.3 
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5.3.2.3 Activation process 

Each SFR enabled Feed Reader must perform at least once the "Activation for Syndicated Feed Reception" procedure 
as defined in this section before using any other syndicated feed optimization procedure. 
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Figure 4: Activation and registration Procedure 

The procedure uses a subset of OMA DCD procedures, namely the Client Activation (defined in section 7.1.3.1 of [5]) 
and the Application Registration (defined in section 7.1.3.3 of [5]) procedures. Client activation procedure and 
application registration procedure are separate transactions to allow an OMA DCD like implementation of syndicated 
feed reception. 

Information Elements (IE) of the ClientActivationRequest Message: 

• Device-ID: Optional in OMA DCD and SFR. 

• Version: The Version IE is mandatory in OMA DCD and SFR. The Version shall take the value "SFRl.O". 
Information Elements of the ClientActivationResponse Message 

• Session-ID: Conditional in OMA DCD and SFR. The SFR server provides the Session-ID in case of successful 
client activation. The "Session-ID" is used in subsequent transactions with the SFR server. 

Information Elements of the ApplicationRegistrationRequest message: 

• Session-ID: Mandatory in OMA DCD. The Session-ID value is provided during ClientActivationResponse. 
Usage for SFR is mandatory. 

• Application-Profile including the channel-selection-metadata: Mandatory in DCD. Relevant subset of DCD 
metadata for SFR is defined in section 5.7. 

Information Elements of the ApplicationRegistrationResponse message: 

• Session-ID: Mandatory in OMA DCD and SFR. 

• Message-ID: Mandatory in OMA DCD and SFR. 

• Channel-Guide including general-channel-metadata: Mandatory in OMA DCD and SFR. Relevant subset of the 
general channel metadata for SFR is defined in section 5.7. 

The activation procedure may include authentication and authorization transactions. Authentication and Authorization 
shall follow "HTTP Digest Authentication" as defined in section 10.1.1.2 of [5]. 
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The SFR enabled Feed Reader may combine multiple requests (ClientActivationRequest, 

ApplicationRegistrationRequest and ChannelSubscriptionRequest (see section 5.4) into a single request using multipart 
HTTP requests. With this approach the assumption is that authentication (basic, digest, or TLS) associated with 
activation request is sufficient to facilitate registration and subscription combined into the single transaction with 
activation. In other words, as registration and subscription requests are bundled with authenticated activation request 
there's no need to send session ID with these requests. 

5.3.2.4 Deactivation process 

The deactivation process can be initiated by the SFR enabled Feed Reader or by the SFR server. 

The process for SFR enabled Feed Reader initiated deactivation process is specified in section 7.1.3.2 of [5] and the 
information elements contained in the ClientDeactivationRequest and ClientDeactivationResponse messages are 
specified in section 7.1.3.2.1 of [5] 

The process for SFR server initiated deactivation process is specified in section 7.1.3.2.2 of [5]. 

5.3.3 Activation triggered by the network 

Upon discovery of an external feed, the SFR enabled Feed Reader is provided with a feed URL The SFR enabled Feed 
Reader shall be able to identify whether this feed is associated with a new SFR server. 

The SFR enabled Feed Reader fetches the feed URI and provides the SFR UAProf parameters as part of the request. 
Upon reception of such parameters, the SFR server initiates the activation process with the SFR enabled Feed Reader. 

The SFR enabled Feed Reader shall pass the UAProf with the following SFR extensions when sending the HTTP GET 
discovery request message to the feed URI. 

Attribute = SFR Version 

Attribute = DevicelD 
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Figure 5: Activation triggered by tlie network 

Upon receipt of the extended UAProf, the new SFR server shall send to the SFR enabled Feed Reader a 
RequestForClientActivation message as specified in section 7.1.3.1.2 of [5]. This is followed by a 
ClientActivationRequest and Client ActivationResponse as specified in section 5.3.2.3. Upon completion of the 
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activation process the SFR enabled Feed Reader registration and channel subscription request as specified in sections 
7.1.3.3 and 7.1.3.7 of [5] are issued. 

The SFR enabled Feed Reader may combine all 3 requests into a single request using multipart HTTP requests. With 
this approach the assumption is that authentication (basic, digest, or TLS) associated with activation request is sufficient 
to facilitate registration and subscription combined into the single transaction with activation. In other words, as 
registration and subscription requests are bundled with authenticated activation request there's no need to send session 
ID with these requests. 

Information Elements (IE) of the RequestForClientActivation Message: 

If the feed is available at an SFR server with which the SFR enabled Feed Reader is configured with; the 
RequestForClientActivation message shall contain only the dcd-3-connection-profile-name parameter specified in 
section 7.1.3.1.2 of [5] shall be used. 

If the feed is available at a new SFR server, the RequestForClientActivation message shall only contain the dcd-3- 
connection-profile parameters specified in section 7.1.3.1.2 of [5]. 

Information Elements (IE) of the SFR enabled Feed Reader registration and channel subscription request messages are 
specified in sections 5.2.2 and 5.3.2.3. 

5.4 Optimized reception initiation of a syndicated feed 

5.4.1 Introduction 

The sections below specify the methods for initiating the optimised reception of feeds, whether the initiation is triggered 
by an external component,by the SFR enabled Feed Reader, or by the SFR server. 

5.4.2 Optimized reception initiation triggered by the UE 

The reception initiation for optimized reception procedure may be triggered when a UE subscribes to a syndicated feed. 
A UE subscribes to a syndicated feed, when it is interested in the content updates provided in this syndicated feed. 

The SFR enabled Feed Reader registers with the SFR server to enable optimized reception of syndicated feed updates 
and its enclosures and attachments (e.g. images). The "activation for syndicated feed reception" procedure (section 5.3) 
shall be executed at least once before the reception initiation procedure. 

The SFR server may need to establish a relation with the Syndicated Feed Provider to become aware about new content. 
If the Syndicated Feed Provider is a DCD Content Provider, then the SFR server should use procedures as defined in 
section 7.2.1 of [5] for the OMA CPR interface. In a scenario whereby the syndicated feed provider is not a "DCD 
Content Provider" and does not support the OMA-CPR interface, the SFR server retrieves the content from the 
syndicated feed provider via an HTTP GET request and inserts the relevant metadata in the feed both for optimised 
handling of enclosures and for optimised delivery. 



ETSI 



3GPP TS 26.150 version 10.0.0 Release 10 



15 



ETSI TS 126 150 VI 0.0.0 (2011-04) 



SFR enabled 
Feed Reader 




SFR 
Server 




Syndicated 
Feed Provider 


i_ 




J 








1 Activation for Syndicated Feed Reception 

L 


-' 






ChannelSubscriptionRequest 








ChannelSubscriptionResponse 


^ 








content update relation 

establishment ! 


















1 
1 
1 



Figure 6: Reception Initiation triggered by the UE 

The Reception Initiation procedure (see figure 6) uses a subset of the OMA DCD Channel Subscription Procedure (see 
section 7.1.3.7 of [5]). 

Information Elements of the ChannelSubscriptionRequest message: 

• Session-ID: Mandatory in OMA DCD and SFR. 

• Message-ID: Mandatory in OMA DCD and SFR. 

• Delivery-personalization-Metadata: Conditional in OMA DCD and SFR. Delivery-personalization-metadata 
contains at least the Channel-ID. In SFR the Channel-ID shall take the value of the feed address. The relevant 
subset of delivery personalization metadata for SFR is defined in section 5.7. 

• Channel-ID: Conditional in OMA DCD and SFR. 

• Subscription-ID Conditional in OMA DCD and SFR (issued upon subscription personalization). 
Information Elements of the ChannelSubscriptionResponse message: 

• Session-ID: Mandatory in OMA DCD and SFR. 

• Message-ID: Mandatory in OMA DCD and SFR. 

• Channel-Metadata (delivery-preference-metadata): Optional in OMA DCD and SFR. If delivery-preference- 
metadata is return, the feed address is provided as the value of the channel-id. Relevant subset of the delivery- 
preference metadata for SFR is defined in section 5.7. 

NOTE: The Channel-Metadata is used to describe the type of "Push" bearer used for syndicated feed delivery. 

The dcd-interface attribute has the value "DCD-2/Point-to-Point" when OMA Push is used for reception. 
Other values to indicate the usage of MBMS Download are described in section 5.7. 

The delivery over MBMS might be done via the DCD OMA-BCAST adaptation specification or as an MBMS direct 
adaptation specification as described in section 5.6. 

5.4.3 External triggered optimized reception initiation 

The user discovers a feed via other means (e.g. from an operator's web portal) and subscribes the UE externally (e.g. 
using a PC) for optimized syndicated feed reception. The user provides the relevant information (e.g. MSISDN) to 
receive the syndicated feed on its UE. 
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Figure 7: Reception Initiation triggered by an external device 

If an external device triggers the Reception Initiation through the SFR server, a subset of the OMA DCD Channel 
Subscription Notification Procedure (see section 7.1.3.9 of [5]) is used (see figure 7). 

Information Elements of the ChannelSubscriptionNotification message: 

• Session-ID: Mandatory in OMA DCD and SFR. 

• Message-ID: Mandatory in OMA DCD and SFR. 

• AppHcation -ID: Mandatory in OMA DCD and SFR. 

• Subscription-ID Conditional in OMA DCD and SFR (if issued upon subscription personalization). 

• Channel-Metadata: General-channel-metadata are mandatory, delivery-preference-metadata are conditional. 
Relevant subset of the channel metadata defined in section 5.7. 

Information Elements of the ChannelSubscriptionNotificationResponse message: 

• Session-ID: Mandatory in OMA DCD and SFR. 

• Message-ID: Mandatory in OMA DCD and SFR. 

• Channel-Metadata (delivery-personalization-metadata): Mandatory in OMA DCD and SFR. The relevant 
subset of the delivery-personalization-metadata is defined in section 5.7. 

NOTE: To perform the subscription, the client must be activated as specified in section 5.4. 



5.5 Reception Termination 



Reception termination corresponds to the procedure, when a UE decides to discontinue optimized reception of 
syndicated feed updates. 



ETSI 



3GPP TS 26.150 version 10.0.0 Release 10 



17 



ETSI TS 126 150 VI 0.0.0 (2011-04) 



SFR enabled 
Feed Reader 



SFR 
Server 



ChannelUnsubscriptionRequest 



ChannelUnsubscriptionResponse 



Figure 8: Reception Termination 

The Reception Termination procedure (see figure 8) uses a subset of the OMA DCD Channel Unsubscription Procedure 
(see section 7.1.3.8 of [5]). 

Information Elements of the ChannelUnsubscriptionRequest message: 

• Session-ID: Mandatory in OMA DCD and SFR. 

• Message-ID: Mandatory in OMA DCD and SFR. 

• Channel-ID: Mandatory in OMA DCD and SFR... 

NOTE: The Channel-ID takes the value of the "Content Address" (i.e. the Syndicated feed URI). 
Information Elements of the ChannelUnsubscriptionResponse message: 

• Session-ID: Mandatory in OMA DCD and SFR. 

• Message-ID: Mandatory in OMA DCD and SFR. 



5.6 Content Reception 



The SFR enabled Feed Reader uses the "Push" interface for optimized reception. The "Push" interface uses the DCD-2 
interface and related procedures. Note that DCD-2 transactions are partly built on DCD-1 transactions: 

• Content Update Push procedure: ContentUpdate Push message and optionally ContentDeliveryConfirmation 
message 

• Content Update Notification procedure: ContentUpdateNotification message, ContentUpdateRequest message, 
ContentUpdateResponse message and optionally ContentDeliveryConfirmation message. 

The DCD-2 interface binds to: 

• OMA-PUSH as specified in [5]. SFR enabled Feed Reader shall support OTA-WSP notifications and may 
support other OMA-Push features. The SFR server shall use OTA-WSP for the content update push procedure 
and the Content Update Notification procedure for larger transmissions. The SFR server may support other 
OMA-Push features. 

• MB MS delivery if supported: 

Via DCD adaptation to BCAST. This is optional to support for both the SFR server and SFR enabled 
Feed Reader. 

Via MEMS direct adaptation specification for DCD procedures as follow: 

o When MBMS is supported, the SFR enabled Feed Reader and the SFR server shall support the mbms- 
access-info parameters in the DCD-2-broadcast-profile element as described in section 5.9 

o Via OTA-PTM (if supported) 

The SFR enabled Feed Reader may use the "Pull" interface for optimized reception. This can be used when the content 
provider specify that the content can be retrieved in "pull" as per the content network-preference metadata. The "Pull" 
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interface uses a sub-set of DCD-1 interface that corresponds to the Content Update procedure, wich is widely aUgned 
with the Content Update Notification procedure of the "Push" interface. The Content Update procedure consists of the 
ContentUpdateRequest, ContentUpdateResponse and optionally the ContentUpdateConfirmation messages. request, 
ContentUpdate response and ContentUpdateConfirmation as specified in section 7.1.1.1. 

Other DCD procedures (e.g. Content Submission procedure) specified for the DCD-1 interface may be supported by 
some implementations but are not required for SFR enabled Feed Readers and SFR servers 1.0. 



5.7 SFR profile of DCD 



5.7.1 Procedure 

The SFR profile defines the set of DCD procedures that an SFR enabled Feed Reader and an SFR server supports: 
SFR enabled Feed Reader and an SFR server shall support the following DCD procedures: 

- Channel Discovery (section 7.1.3.10.3 of [5]) 

- Activation (section 7.1.3.1 of [5]) and deactivation (section 7.1.3.2 of [5]) 

- Application Registration (section 7.1.3.3 of [5]) and deregistration (section 7.1.3.4 of [5]) 

- Channel Subscription (section 7.1.3.7 of [5]) and un- subscription (section 7.1.3.8 of [5]) 

- Channel Suspend and Channel Resume (section 7. 1 .3. 1 1 of [5]) 

- Syndicated Feed Delivery over DCD-2 using OMA Push and MBMS if these delivery methods are supported on 
the device 

- Syndicated Feed Delivery over DCD-1 

- Embedding DCD metadata into RSS and Atom feeds as per sections 9.2 and 9.3 of [5] 
Other DCD procedures may be supported but are not required for this specification: 

- Content Submission 

- Usage tracking report 

- Channel Subscription Update 

- Content Repair 

- Contextual Information Update 

- Channel Metadata update 

- All procedures between DCD client and DCD enabled Client Application 
All procedures between DCD servers and DCD content providers 

5.7.2 Metadata 

5.7.2.1 Application Profile Metadata 

The SFR enabled Feed Reader and the SFR server shall support the following subset of DCD application profile 
metadata as specified in section 8.1.2 of [5]: 

"application-profile" element with the following attributes: 

"application-id" 

"dcd-channel-selection-metadata" element 
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5.7.2.2 



Channel Selection Metadata 



The SFR enabled Feed Reader and the SFR server shall support all Channel Selection metadata as specified in 
section 8.2.2.1.1 of [5]. 



5.7.2.3 



Delivery Personalisation Metadata 



Channel Delivery personalisation metadata listed below, as specified in section 8.2.2.1.2 of [5], with specific values for 
particular parameters. The Channel delivery personalization metadata is always sent from client to server: 

"channel-id" attribute: either RSS URL or value of "atom:id" 

"content-availability-notification" attribute: The SFR enabled Feed Reader should set this to "true" 

"deli very- when-roaming" attribute: default False 

"dcd-2-broadcast-profile" element with the following additional sub -parameters (Mbms-access-info and usd- 
description) to support the direct binding to MBMS: 
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5.7.2.4 



General Channel Metadata 



The SFR enabled Feed Reader and the SFR server shall support the following DCD general channel metadata as 
specified in section 8.2.2.2.1 of [5] with the following values. The general channel metadata is provided from the SFR 
server to the SFR enabled Feed Reader: 

- DCD Channel-ID: SFR server or SFR Feed provider shall use the DCD Channel ID for identification of the RSS 
feed. The value of Channel ID shall be identical to the RSS feed URL. In the case of Atom feed, the DCD 
Channel ID shall take the value of the "atom:id" element. 

- DCD Content-type : This metadata parameter is provided by SFR server and used by SFR enabled Feed Reader 
to filter available syndicated feeds in the channel guide. It is used at channel/feed discovery stage to enable the 
SFR server to match application preferences and available feeds and to create a subset of channels/feeds that 
correspond to the preferences of installed SFR enabled applications. This subset is returned to device during 
channel discovery and the SFR client enables subscription to the particular feeds. The DCD content-type 
corresponds to the rss category or atom: category fields. 

- DCD Mime-type: This metadata parameter is provided to indicate needed mime type support to correctly receive 
the syndicated feed. This parameter is used at channel/feed discovery stage e.g. filtering relevant channels and 
content for the UE: 

- By SFR enabled Feed Reader to announce capabilities (i.e. supported mime-types). 
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- By SFR server to announce types of syndicated feeds and of media content included in the enclosures of the 
syndicated feeds in the channel. RFC 4281 shall be used to indicate the mime-type. 

The SFR enabled Feed Reader and the SFR server may support the following DCD general channel metadata, as 
specified in section 8.2.2.2.1 of [5], that corresponds to some ATOM or RSS feed metadata. If these DCD metadata are 
supported, the value of equivalent parameters in ATOM or RSS shall be used as values for the corresponding DCD 
metadata: 

- DCD Channel-name: This DCD channel metadata corresponds to the RSS Channel Title and/or to the ATOM 
Feed.title parameter. 

- DCD Updated: This DCD channel metadata corresponds to the RSS channel lastbuildDate and/or to the ATOM 
feed.updated parameter. 

- DCD channel-description: This DCD channel metadata corresponds to the RSS channel description and/or to the 
ATOM feed. subtitle parameter. 

- DCD genre: This DCD channel metadata corresponds to the RSS channel category and/or to the ATOM 
feed.category. 

- DCD channel-icon: This DCD channel metadata corresponds to the RSS channel image and/or to the ATOM 
feed.icon/ feed.logo. The DCD Channel-icon provides a mime-type attribute that is not available in ATOM and 
RSS. 

Other general channel metadata as described in [5] and not listed above may be supported but are not required for SFR. 

5.7.2.5 Delivery preference metadata 

The delivery preference metadata listed below, as specified in section 8.2.2.2.3 of [5], with specific values for particular 
parameters, shall be supported. Delivery preference metadata are provided either by feed provider or SFR server: 

"channel-id" attribute: either RSS URL or value of "atom:id" 

"dcd-interface": 

- "DCD-2/point-to-point": OMA-Push with point-to-point bearers 

- "DCD-2/Broadcast": Content deHvery with MBMS Download deHvery method in case of direct MEMS 
binding 

- "DCD-1/HTTP(S)": Content reception using unicast UMTS bearer services 
"dcd-2-broadcast-profile" with the additional element "Mbms-access-info" define in section 5.7.2.3. 

5.7.2.6 Content Metadata 

Content Metadata are provided by the feed provider. In SFR, content metadata are RSS and ATOM metadata and may 
consist of DCD Content metadata. The SFR server can update or add some DCD metadata to the content metadata 
received from the feed provider. 

If the syndicated feed provider uses the DCD content metadata, or if the SFR server extends the feed metadata with 
DCD metadata, then the following shall apply: 

The SFR enabled Feed Reader and the SFR server shall support the DCD content metadata as specified in section 8.3.2 
of [5] and with the particular limitations described below: 

- DCD mime-type: This parameter shall be used by SFR to indicate the expected mime-type of the content item 
and of the enclosure in the item. RFC 4281 shall be used to indicate the mime-type. 

- DCD replace-content-id: this parameter shall be used by SFR to indicate which content item shall be replaced by 
the content item for which a content-id (RSS item guid and/or ATOM feed. entry. id) is provided in the same 
message. 
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The SFR enabled Feed Reader and the SFR server may support the following DCD content metadata as specified in 
section 8.3.2 of [5] that corresponds to some ATOM or RSS entry metadata. If these DCD metadata are supported, the 
value of equivalent parameters in ATOM or RSS shall be used as values for the corresponding DCD metadata: 

- DCD content-id: This DCD content metadata corresponds to the RSS item guid and/or to the ATOM 
feed.entry.id parameter. 

- DCD content-name: This DCD content metadata corresponds to the RSS item title and/or to the ATOM 
feed.entry.title parameter. 

- DCD content-update: This DCD content metadata corresponds to the ATOM feed.entry.updated parameter. 
There is no equivalent parameter in RSS. 

5.7.2.7 Other DCD Metadata 

Other DCD metadata may be supported but are not required for SFR vl.O: 
Charging metadata as specified in section 8.2.2.2.1 of [5] 



Optimized handling of enclosure 



6.1 Introduction 

SFR provides a method of advertising, before retrieval, all required codecs/profiles/levels within a media file reference. 
SFR also allows the description of either alternative enclosures or the definition of tailored syndicated feeds for specific 
devices capabilities.. 

Unless the client on the UE requests a special SFR defined alternate enclosure the handling of enclosure is independent 
of optimized reception, hence a regular ATOM/RSS server may be capable of providing feeds with optimized 
enclosure. 

6.2 RSS enclosure 

RSS schema has dedicated XML element for enclosure. "Enclosure" element in RSS [3] has three required attributes: 
"url", "length", and "type". 

An SFR feed provider shall use the type attribute to specify the relevant 3 GPP Mime type and Codec as specified in 
RFC 4281 of the referenced content that is in a 3GP format. 

An SFR parser shall determine from the type attribute the mime type and codec associated with the referenced content 
and, upon determining whether the content is usable on the UE, retrieve it, if usable. 

Example of RSS enclosure using RFC 4281 and TS 26.244: 

<enclosure url="http://www.scripting.com/videos/weatherReportSuite.3gp" length^" 12216320" type=" video/3 gp; 
codecs=" s263, samr "" /> 

6.3 ATOM enclosure 

Enclosure in ATOM [4] is specified by using the link' element with the "rel" attribute value set to "enclosure". The 
other three attributes of the 'link' element used to specify enclosure parameters are "type", "length" and "href". 

An SFR feed provider shall use the type attribute to specify the relevant 3 GPP Mime type and Codec as specified in 
RFC 4281 of the referenced content that is in a 3GP format. 

An SFR parser shall determine from the type attribute the mime type and codec associated to the referenced content 
and, upon determining whether the content is usable on the UE, retrieve it, if usable. 

Example of ATOM enclosure using RFC 4281 and TS 26.244: 
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link rel=" enclosure" type=" audio/3 gp; codec=" samr " " length="1337" 
href=http ://example.org/audio/ph34r_my_podcast. 3gp 

6.4 Providing alternative enclosures 

Content Provider can publish media content in multiple formats, some matching UE capabilities, some not. There are 
three methods to provide tailored enclosures for UE capabilities: 

- Alternative description in the syndicated feeds: The syndicated feed is extended to include multiple versions of 
the same content. An example is provided below for ATOM. Other ways are possible for both ATOM and RSS. 

- Alternative syndicated feed channels: The feed aggregator creates tailored syndicated feeds, which all match the 
device capabilities. 

- Alternative delivery of enclosure based on the requesting device: The server selects the correct version of the 
content, when the device requests the enclosure. 

The feed provider or the SFR server may offer syndicated feeds tailored for device classes. The SFR server in case of 
optimized delivery can use the DCD content type and DCD-Mime Types parameters to associate the registering device 
to the matching tailored syndicated feed. 

Additionally, the syndicated feed server may offer alternative versions of media content, either based on the knowledge 
of UE capabilities or just based on alternative version availability. 

In such a case, the enclosure support in ATOM/RSS will be reused for primary enclosure as per section 6.2 and 6.3 
above. 

Alternative enclosures could be used to specify alternative formats for the media content. 

An syndicated feed server may include alternative enclosure in the RSS feed: 

- if it is aware of the UE capabilities and there are multiple available versions of the same media content in 
formats usable by the UE. This applies both to the optimised and non optimised delivery mode. 

- or if the SFR server is not aware of the UE capabilities and the format of media content in primary enclosure 
may not be usable by the UE. This may apply to the non optimized delivery mode. 

An SFR enabled Feed Reader should add the UAProf header [1 1] to all HTTP requests. If a feed provider or SFR server 
wants to personalize the response to device capabilities, the server should interpret the UAProf header and send an 
according response, e.g. enclosure codecs settings, which match the device capabilities. 

It is also possible to describe multiple enclosures in the syndicated feeds. For instance, the ATOM format [4] allows 
providing multiple enclosure links in a single entry for the purpose of providing alternative media formats or content 
formats relating to the Entry. 

An alternative enclosure in SFR for ATOM can be defined as follow: 

- Multiple "rel" attributes with values set to "enclosure" are used in a single parent entry element. 

- The "type" attribute value in the enclosure links are specified according to section 6.1 
Example of alternative enclosure in ATOM: 

<entry> 

<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> 

<link rel="enclosure" type="audio/aac" length="1337 
href=http://example.org/audio/ph34r_my_podcast.aac/> 

<link rel="enclosure" type=" audio/3 gp; codec=" samr "" 
href=rtsp ://example.org/audio/ph34r_my_podcast. sdp/> 

</entry> 
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7 Media codecs and formats for syndicated feeds 

7.1 Media Transport for enclosures 

This section defines the media transport formats for Syndicated Feed Reception. 

Syndicated Feed Reception supports progressive reception and rendering of 3GP files received using HTTP and packet 
switched streaming (PSS) sessions. A UE including reception support for 3GP files as defined in 3GPP TS 26.234 [6] 
should support Basic profile, Extended-presentation profile and Progressive-download profile as defined 3 GPP TS 
26.244 [7]. The UE shall support the mime type parameters as defined in RFC 4281 [10] and should support Annex A of 
3GPPTS 26.244 [7], 

Syndicated Feed Reception supports RTP streaming sessions as defined in Packet Switched Streaming (PSS) with URIs 
as enclosures. A UE including a Packet Switched Streaming (PSS) client as defined in 3GPP TS 26.234 [6] should 
accept Packet Switched Streaming RTSP URIs as enclosures. 

The Syndicated Feed Reader may receive linked files over MBMS and OMA Push. 

7.2 Media codecs and formats 

This section defines the default media formats and codecs supported syndicated feed reception. 

PSS Media codecs and formats decoding capabilities defined in 3 GPP TS 26.234 [6] are applicable to the present 
syndicated feeds, including in particular text and image, graphics codecs and formats. 
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Annex A (informative): 
Interaction examples 



This annex contains a set of informative interaction examples between SFR enabled Feed Readers, SFR server and feed 
servers. There are several alternatives to discover and subscribe to syndicated feeds. 

• Feed Discovery using the UE Browser 

• Feed Discovery using the Syndicated Feed Reader 

• SFR Server Discovery triggered by Feed Discovery 

• Feed Discovery using the PC Browser 



A.1 Feed Discovery using the UE browser 

This informative example scenario assumes syndicated feed discovery through the UE browser (example external 
application). The scenario assumes that the SFR enabled Feed Reader has configured a "default" SFR server. It also 
assumes that feed announcement and the actual syndicated feed are served from different HTTP servers. 

The UE browser is used in this example to discover the syndicated feed. Syndicated feeds may use the auto-discovery 
techniques to simplify identification of syndicated feed URI for the browser. One or more auto-discovery tags are added 
into the head-section of the HTML file. An example of an auto-discovery tag is given below. 

<html> 
<head> 

<title>...</title> 

<link rel= "alternate" type="application/rss+xml" title= "Example Feed" 
href ="http: //feeds .example . com/ExampleNewsFeed. rss"> 
</head> 
<body> 

<!-- the web page's contents --> 
</body> 
</html> 

This example auto-discovery tag announces the URI of an RSS feed with the title "Example Feed" and the MIME Type 
"application/rss+xml" . 

The following figure depicts the sequence flow for the feed discovery using a browser. It includes also the Reception 
Activation transaction and a Content Update Reception. 
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Figure A.1 : Feed Discovery using the UE Browser 

1. The user uses a browser to find syndicated feeds. Note: syndicated feed discovery using the UE 
browser is one realization of syndicated feed discovery and not in scope of this specification. 

2. When the user finds a syndicated feed of interest and subscribes to it, the browser hands-over the feed 
URI to the SFR enabled Feed Reader. If the client has not performed the activation procedure with the 
server, it runs the "activation for syndicated feed reception" procedure as defined in section 5.3. 

When the client has run the activation procedure with the SFR server, the client initiates the optimized 
feed reception as defined in section 5.4. The syndicated feed URI (received from the browser) is used 
as "Channel-ID" or "Content- Address" in the reception initiation procedure. 

The ChannelSubscriptionResponse contains the Channel-Metadata structure. If content update 
notification is delivered using OMA push, then the "dcd-interface" element in the channel metadata 
contains the value "DCD-2/Point-To-Point". 

If content update notification is delivered using MBMS, then the "dcd-interface" element in the 
channel metadata contains the value "DCD-2/Broadcast". The "network-preferences" element shall 
contain the string "MBMS" in that case. 

The SFR server has established a "Content update" relation with the desired syndicated feed server. In 
a scenario whereby the syndicated feed provider is not a "DCD Content Provider" and does not support 
the CPR interface and messages exchanged over the CPR interface, the SFR server retrieves the 
content from the syndicated feed provider via an HTTP GET request and inserts the relevant metadata 
in the feed both for optimised handling of enclosures and for optimised delivery. 

3. Content Updates are received. 



A.2 Feed Discovery using the Syndicated Feed Reader 

The SFR enabled Feed Reader may provide a build-in function to select and subscribe to syndicated feeds. The SFR 
enabled Feed Reader fetches the list of available feeds from the SFR server. 
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Figure A.2: Feed Discovery using the SFR enabled Feed Reader 

1 . The SFR enabled Feed Reader must have previously executed once the OMA DCD activation and 
registration procedures. The SFR enabled Feed Reader gets a list of available syndicated feeds in the 
ApplicationActivationResponse message. 

2. The SFR enabled Feed Reader may send a request to update the list of syndicated feeds, when a user 
starts browsing the available syndicated feeds. 

3. When the user finds a syndicated feed of interest, the SFR enabled Feed Reader sends the 
ChannelSubscriptionRequest message to the SFR server to initiate the optimized reception of the feed. 
The Content Address contains the URI of the syndicated feed. 

The ChannelSubscription Response contains a Channel Metadata. If content update notification is delivered using OMA 
push, then the "dcd-interface" element in the channel metadata contains the value "DCD-2/Point-To-Point". Other 
channel metadata are defined for OMA DCD. 

If content update notification is delivered using MBMS, then the "dcd-interface" element in the channel metadata 
contains the value "DCD-2/Broadcast". The "network-preferences" element shall contain the string "MBMS" in that 
case. 

The SFR server has established a "Content update" relation with the desired syndicated feed server. In a scenario 
whereby the syndicated feed provider is not a "DCD Content Provider" and does not support the CPR interface and 
messages exchanged over the CPR interface, the SFR server retrieves the content from the syndicated feed provider via 
an HTTP GET request and inserts the relevant metadata in the feed both for optimised handling of enclosures and for 
optimised delivery. 



A.3 SFR Server Discovery triggered by Feed Discovery 

The syndicated feed is served through a new SFR server. The terminal needs to discover the new SFR server or needs to 
be discovered as an SFR capable terminal by this new SFR server. It may also happen that the UE has no "default" SFR 
server configured. 
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The SFR enabled Feed Reader can activate and register to a new SFR server when the SFR feed URI contains the SFR 
server connection information as specified in section 5.3.2.2. 
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Establish „Content Update" relation 
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Figure A.3: SFR Server Discovery triggered by Feed Discovery 

4. The user browses and discovers a feed URI. The browser pass the URI to the SFR enabled Feed 
Reader. The SFR enabled Feed Reader retrieves from the URI the SFR server parameters. 

5. The SFR enabled Feed Reader uses the SFR server connection parameters to activate and further 
register to the SFR server and provide the feed URI to the SFR server. The SFR server establishes a 
content update relation with the feed server if not already in place. 

6. Content updates are received. 

Alternatively, the SFR enabled Feed Reader can be activated by a new SFR server as the SFR enabled Feed Reader 
provides its SFR UAProf capabilities when fetching the feed URI as specified in section 5.3.3. 
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Figure A.4: activation triggered by SFR Server 

1 . The terminal fetches a feed URI and provides its SFR UAprof parameters as part of the request. The web 
server forward these information to the SFR server. Alternatively, as per figure 5 in section 5.3.3, upon 
reception of the feed URI, the SFR enabled Feed Reader requests the feed to the SFR server and provides 
itq SFR capabilities as part of the UAprof information element. 

2. The SFR server sends a request for activation notification to the SFR enabled Feed Reader (e.g. via SMS 
message). 

3. Upon completion of the activation/registration process, content updates are received. 



A.4 Feed Discovery using the PC browser 

This informative example assumes syndicated feed discovery through the PC browser (example external application). 
The example requires, that the SFR enabled Feed Reader has configured a "default" SFR server. 

The user discovers a feed via other means (e.g. from a web portal) and provides the relevant information (i.e. a delivery 
context) to receive the feed on its SFR terminal. The feed is routed via the SFR server to which the terminal is 
connected. (For instance, if a phone number is identified as belonging to a particular mobile network operator the feed 
provider knows the SFR server of that carrier) 

The figure bellow illustrates the flow for external subscription to an external feed and corresponds to DCD figure 9, 
flow 3 as described in [5]. 
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Figure A.5: Feed Discovery using an external device 

Upon reception of the some subscription notification from the web portal, the SFR server sends a 
ChannelSubscriptionNotification message to the SFR enabled Feed Reader via the DCD-3 interface as specified in 
section 7.1.3.9 of [5]. 

The SFR enabled Feed Reader processes this message and returns a ChannelSubscriptionNotificationResponse to the 
SFR server as specified in section 7.1.3.9 of [5]. 

1) The user uses a browser to find and subscribe to syndicated feeds on the service provider's portal. Note: 
syndicated feed discovery using the PC browser is one realization of syndicated feed discovery and not in 
scope of this specification. The assumption is that the UE is configured with the SFR server associated with 
the service provider's portal. The user provides as part of the subscription process some information allowing 
to identify the UE (e.g. MSISDN). Upon completion of the subscription process, the SFR server is provided 
with the feed address and the UE information. 

2) The SFR server sends a ChannelSubscriptionNotification message to the UE as specified in section 7.1.3.9 of 
[5]. (e.g. this may be done via an SMS message) The user confirms the channel subscription and a 
ChannelSubscriptionNotificationResponse is sent from the UE to the SFR server as specified in section 
7.1.3.9.1 of [5] 

3) content updates are received. 
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